I'm skeptical there is a benefit to this. HasRawDisplayHandle and HasRawWindowHandle imply that the implementer either owns the underlying handle(s) or borrows the handles (which would require following the contract of the API).

Regarding the comparison to AsRawFd I feel HasRawWindowHandle differs in the semantics. If an fd is closed and you use the fd somewhere, you'll get some errno or io::Error return value. Whereas with raw window/display handles you are likely passing around a pointer which on some platforms could be dangling if the owner of the handles is freed.

They're unsafe to implement now, as contrasted with AsRawFd in the standard library, which are safe.

The safety, and possibly the existence, of this trait is arguably just a relic of it predating IO safety. And the fact that can't be changed.

Is HasRawWindowHandle still needed? Or would it be better for all implementers to just implement HasWindowHandle, and get a raw window handle from that, as needed? Is there any reason to implement HasRawWindowHandle but not HasWindowHandle?

If an fd is closed and you use the fd somewhere, you'll get some errno or io::Error return value.

Not necessarily. The fd may have been re-used, and may now point to a different file description. Which may be mapped into memory, so you may cause undefined behavior by writing to it.

So you might get an IO error, but that can also be unsound, and that is basically the reason for the IO safety rules and types.

If I recall the end goal of the regular WindowHandle type is to make the whole process of getting a softbuffer/gl context/etc safe. However that would need a lifetime on context types? So a Display<'a> for example. But some use cases you pretty much can't have a lifetime, (wayland-rs Dispatch: 'static is very guilty of this). I guess you could transmute a Display<'a> to a Display<'static> but that would require writing transmutes and you are heavily discouraged from doing that plus it's a UB nightmare waiting to happen.

I guess ouroboros could be a workaround to the "context needs to be owned with the display" scenario but using ouroboros feels unclean.

I agree with the rationale presented here, so I’ll close this PR.

The intended solution to the problem of a borrowed window handle having a lifetime parameter is to pass around the T: HasWindowHandle itself. I've applied this pattern to my conversions so far, see rust-windowing/softbuffer#132, gfx-rs/wgpu#3932 and rust-windowing/glutin#1582. This way you can use WindowHandle<'a>, Rc<Window> and Arc<Window> in all of these places without any issues.

ouroboros is sketchy, I agree.